Systems and methods relating to digital identities

ABSTRACT

Systems and methods are provided for use in responding to attribute queries related to identifying information for a user. One exemplary method includes receiving a request for an identity code for a user associated with identifying information, where the identifying information includes multiple attributes of the user, and generating the identity code and transmitting it to a communication device associated with the user, thereby permitting the user to present the identity code to a requesting party. The method then includes receiving an identity request from the requesting party including the identity code and at least one query related to at least one of the multiple attributes of the user, identifying the user based on the identity code, compiling a response to the at least one query based on the identifying information of the user at one or more attributed providers, and transmitting the response back to the requesting party.

FIELD

The present disclosure generally relates to systems and methods formanaging user identities and, in particular, to systems and methods foruse in providing responses to inquiries for certain users based onconfirmation of digital identities related to the users.

BACKGROUND

This section provides background information related to the presentdisclosure which is not necessarily prior art.

People are generally associated with identities, which include names ofthe people, addresses, government identification numbers, etc. And, inconnection with opening accounts, or otherwise interacting withbusinesses (e.g., applying for insurance, etc.), for example, people areoften required to present proof of their identities. It is known forpeople to offer proof of their identities by providing government issuedidentifications, such as passports, drivers' licenses, etc., or byproviding other similarly reliable documents (e.g., utility bills,etc.). The documents may often permit the requester of the documents toverify the people's identities and may provide other information aboutthe people (e.g. birthdays, home addresses, etc.). Once the documentsare presented, and the identities of the people are verified, the peopleare often able to continue in opening the accounts or otherwiseinteracting with the businesses. In connection with such continuedprocesses, the businesses may further query the people about theirqualifications for the accounts, such as, for example, income levels,prior transactions, etc. Then, based on the verified identities of thepeople and their subsequent responses relating to their qualificationsfor the accounts, the businesses may be able to move forward with newaccounts for the people or otherwise interact with the people for one ormore other business purposes.

DRAWINGS

The drawings described herein are for illustrative purposes only ofselected embodiments and not all possible implementations, and are notintended to limit the scope of the present disclosure.

FIG. 1 illustrates an exemplary system of the present disclosuresuitable for use in responding to inquiries related to a user based on adigital identity associated with the user;

FIG. 2 is a block diagram of a computing device that may be used in theexemplary system of FIG. 1; and

FIG. 3 is a flow diagram of an exemplary method, which may beimplemented in connection with the system of FIG. 1, for responding toinquiries related to a user based on a digital identity associated withthe user.

Corresponding reference numerals indicate corresponding parts throughoutthe several views of the drawings.

DETAILED DESCRIPTION

Exemplary embodiments will now be described more fully with reference tothe accompanying drawings. The description and specific examplesincluded herein are intended for purposes of illustration only and arenot intended to limit the scope of the present disclosure.

Users often interact with businesses to apply for accounts such as, forexample, banking accounts, investment accounts, insurance accounts,payment accounts, etc., or otherwise interact with the businesses, wherethe businesses, or other entities, in turn seek to verify identities ofthe users and/or attributes of the users. The businesses may, forexample, solicit physical documents from the users, such as drivers'licenses or passports, to verify the identities of the users. Inaddition, the businesses may solicit other data, which may be verifiedby physical documents, or not, and which is usable by the businesses ininteracting with the users. In turn, the users then provide therequested data to the businesses. That said, the physical documents mayreveal additional information about the users, which is not neededand/or requested by the businesses or other entities. For example, acasino business may request an individual to verify his/her age (e.g.,as being 21 years of age or older, etc.) by presenting a physicaldocument including a birthday of the person (e.g., a driver's license,etc.). Often, however, such physical document will include a residentialaddress, a driver's license number, a passport number, a travel history,etc. for the individual.

Uniquely, the systems and methods herein permit users to provisiondigital identities to an identity host, which is configured to thenprovide codes specific to the users, upon request, that are usable(e.g., by the businesses, etc.) to verify attributes of the users.Specifically, for a given user, the identity host captures and stores adigital identity for the user, which is associated with one or moreattribute providers. When the user interacts with a business, or moregenerally, a requesting party, the user requests a code from theidentity host, which is then provided to the business. The business thensubmits the code with a query back to the identity host. In turn, theidentity host responds to the query either directly, or based on aresponse from the one or more attribute providers. The response isgenerally devoid of personal identifying information, or PII, for theuser, or includes only limited PII. For example, the query from thebusiness may include “Is this person 21 years of age and male?” to whichthe identity host may respond with an indicator associated with “yes” or“no.” In this manner, the PII provided by the identity host is eitherlimited or omitted, but with the response still providing the businessthe indicator of the data required to proceed. Thus, this feature of thesystems and methods herein provides improved and/or enhanced security ofPII over existing systems and methods were such information is actuallydisclosed to at least the requesting business.

FIG. 1 illustrates an exemplary system 100, in which one or more aspectsof the present disclosure may be implemented. Although the system 100 ispresented in one arrangement, other embodiments may include the parts ofthe system 100 (or other parts) arranged otherwise depending on, forexample, relationships between users and identity hosts, interactionsbetween the identity hosts and attribute providers, etc.

The illustrated system 100 generally includes an identity host 102,attribute providers 104 and 106, and a requesting party 108, each ofwhich is coupled to (and is in communication with) a network 110. Thenetwork 110 may include, without limitation, one or more of a local areanetwork (LAN), a wide area network (WAN) (e.g., the Internet, etc.), amobile network, a virtual network, and/or another suitable public and/orprivate network capable of supporting communication among two or more ofthe parts illustrated in FIG. 1, or any combination thereof. Forexample, the network 110 may include multiple different networks, suchas a private network made accessible by the identity host 102 to theattribute provider 104 and, separately, the public Internet, which isaccessible as desired to the identity host 102, the attribute provider106, the requesting party 108, and a computing device 112 associatedwith a user 114, etc. It should be appreciated that he computing device112 may include any suitable computing device within the scope of thepresent disclosure, including, for example, a workstation, a personalcomputer, a laptop, a tablet, a smartphone, another communication device(such as another laptop, tablet, smartphone), etc.

The identity host 102 of the system 100 may include any entity providingidentity services to one or more requesting parties and/or users. Inaddition, the identity host 102 may be a standalone entity, asillustrated in FIG. 1, or it may be incorporated into and/or integratedwith, in whole or in part, one or more other entities of the system. Forexample, in some exemplary embodiments, the identity host 102 may formpart of a payment network (not shown), such as, for example, theMasterCard® payment network, etc. As described below, the identity host102 may be configured to provide different roles (e.g., a rootedidentity provider, an identity verifier, etc.). In connection therewith,while the identity host 102 is illustrated as a single entity in FIG. 1(whether alone or as included in another entity of FIG. 1), it should beappreciated that the identity host 102 may be segregated into multipledifferent entities (as indicated by the dotted lines in FIG. 1), witheach entity of the identity host 102 associated with one or more rolesof the identity host 102 (e.g., with at least the rooted identityprovider role being performed as an independent role by the identifyhost 102, etc.).

The attribute providers 104 and 106 of the system 100 include entities,generally separate from the identity host 102, which maintain datarelated to the user 114, etc. The attribute providers 104 and 106 mayinclude any entity that captures and/or stores information about aperson. Such data may include, without limitation, personal identifyinginformation (PII) for the user 114 and may be specific to a type of thegiven one of the attribute provides 104 and 106 at issue. For example,the attribute provider 104 may include an insurance entity, which is theholder of an automobile policy in the name of the user 114. As such, thedata related to the user 114, which is stored at the attribute provider104, may include insurance coverages (e.g., insurance policy types,coverage limits, deductibles, etc.). And, the attribute provider 106 mayinclude a financial institution, with which the user 114 has a paymentaccount. The data related to the user 114, which is stored at theattribute provider 106, may then include transaction data for the user114 (for the payment account) such as transaction frequencies, a numberof transactions in a given term (e.g., ten transactions on average perweek, etc.), an average balance, a current balance, automatic deposits,a number of authorized users for the payment account, etc. In yet otherexamples, the attribute provider 104 may include a telecommunicationcompany (e.g., a mobile phone carrier, a cable carrier, a satellitetelevision carrier, a network provider, etc.), a car company, a companyassociated with one or more mobile applications and/or websites, (e.g.,related to fitness, restaurants, travel, entertainment, socialnetworking, professional associations, or other subject matter, etc.),or other suitable companies, businesses, or entities.

While only two attribute providers 104 and 106 are shown in FIG. 1 forease of reference, it should be appreciated that the system 100 mayinclude multiple attribute providers within the scope of the of thepresent disclosure. For example, it should be appreciated thatadditional and/or different attribute providers (e.g., different fromattribute providers 104 and 106, etc.) may be included in other systemembodiments, which may include five, ten, fifteen, fifty, or evenhundreds or thousands of attribute providers over one or more differentusers, where the attribute provides capture and/or store identifyinginformation about the user(s). That said, in general, each attributeprovider will generally include an entity having relationships with theuser 114, such that some or all of the above data and/or additional ordifferent data may be known to the given attribute provider. In view ofthe above, it should be appreciated that some attribute providers willinclude certain identifying information for the user 114, while otherattribute providers will have the same and/or different identifyinginformation. Thus, for example, the attribute provider 104 may have oneportion of the total identifying information for the user 114 (e.g.,transaction history, driver's license number, social security number,etc.), while the attribute provider 106 may have a different portion ofthe identifying information for the user 114 (e.g., insurance coverages,driver history, etc.).

The requesting party 108 of the system 100 includes an entity, such as,for example, a business, an individual, etc., which offers productsand/or services for consumption by users (including the user 114). Therequesting party 108 may be available to the user 114 as a physicallocation (e.g., a brick-and-mortal location, etc.) and/or a virtuallocation (e.g., a website, a network-based application, etc.), etc. Assuch, in connection with a purchase, rental, or other arrangement for aproduct and/or service between the requesting party 108 and the user114, the requesting party 108 desires and/or may be obligated to verifythe identity of the user 114 and/or certain attributes about the user114. For example, the requesting party 108 may include a rental carbusiness from which the user 114 attempts to rent a car, or therequesting party 108 may include a banking institution from which theuser 114 requests a line of credit and/or a payment account, etc. Inconnection therewith, the requesting party 108 generally interacts withthe user 114 (for a variety of reasons, as described) and seeks to“request” verification of the identity and/or attributes of the user114. Specific interactions between the requesting party 108 and theidentity host 102 and the user 114, as part of such request, aredescribed in more detail below.

In addition in the illustrated system 100, the user 114 is associatedwith an identity, and with certain attributes that form the user'sidentity. Specifically, the identity of the user 114 may include, forexample, a name of the user 114, a gender, a physical address, a phonenumber, an email address, a social security number, a passport number, adriver's license number, account numbers, etc. And, any or all of thisinformation may be evidenced by one or more physical documents, such as,for example, a passport, a driver's license, a birth certificate, autility bill, etc. Similarly, attributes of the user 114 may include,without limitation, an age of the user 114, a gender, a payment accounttransaction history (e.g., prior purchases, etc.), payment accountbalances, credit score(s), insurance coverage, travel history,immunization history, medical history (person or family), travelpreferences (e.g., designation preferences, hotel preferences, airlinepreferences, airline seating preferences, etc.), driving record,location history, web search history, usage of one or more mobileapplications and/or websites, relationship status, voter registration,property ownership, or other suitable attributes, etc.

While the illustrated system 100 includes only one identity host 102,two attribute providers 104 and 106 (as discussed above), and onerequesting party 108, it should be appreciated that more or less of suchentities (as also suggested above) and/or parts may be included in othersystem embodiments. Likewise, additional users and/or computing devicesmay be included in other system embodiments.

FIG. 2 illustrates an exemplary computing device 200 that can be used inthe system 100 of FIG. 1. The computing device 200 may include, forexample, one or more servers, workstations, personal computers, laptops,tablets, smartphones, etc. In addition, the computing device 200 mayinclude a single computing device, or it may include multiple computingdevices located in close proximity or distributed over a geographicregion, so long as the computing devices are specifically configured tofunction as described herein. In the exemplary embodiment of FIG. 1, andas described above, the identity host 102, the attribute providers 104and 106, and the requesting party 108 are each illustrated as including,or being implemented in, computing device 200, coupled to (and incommunication with) the network 110. In addition, the computing device112 associated with the user 114 can also be considered a computingdevice generally consistent with computing device 200 for purposes ofthe description herein. However, the system 100 should not be consideredto be limited to the computing device 200, as described below, asdifferent computing devices and/or arrangements of computing devices maybe used in other embodiments. In addition, different components and/orarrangements of components may be used in other computing devices.

Referring to FIG. 2, the exemplary computing device 200 includes aprocessor 202 and a memory 204 coupled to (and in communication with)the processor 202. The processor 202 may include one or more processingunits (e.g., in a multi-core configuration, etc.). For example, theprocessor 202 may include, without limitation, a central processing unit(CPU), a microcontroller, a reduced instruction set computer (RISC)processor, an application specific integrated circuit (ASIC), aprogrammable logic device (PLD), a gate array, and/or any other circuitor processor capable of the functions described herein.

The memory 204, as described herein, is one or more devices that permitdata, instructions, etc., to be stored therein and retrieved therefrom.The memory 204 may include one or more computer-readable storage media,such as, without limitation, dynamic random access memory (DRAM), staticrandom access memory (SRAM), read only memory (ROM), erasableprogrammable read only memory (EPROM), solid state devices, flashdrives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/orany other type of volatile or nonvolatile physical or tangiblecomputer-readable media. The memory 204 may be configured to store,without limitation, user identities, user attributes, transaction data,interfaces, images of documents, images of the user 114, biometricsassociated with the user 114, other PII, and/or other types of data(and/or data structures) suitable for use as described herein.Furthermore, in various embodiments, computer-executable instructionsmay be stored in the memory 204 for execution by the processor 202 tocause the processor 202 to perform one or more of the functionsdescribed herein, such that the memory 204 is a physical, tangible, andnon-transitory computer readable storage media. Such instructions oftenimprove the efficiencies and/or performance of the processor 202 and/orother computer system components configured to perform one or more ofthe various operations herein. It should be appreciated that the memory204 may include a variety of different memories, each implemented in oneor more of the functions or processes described herein.

In the exemplary embodiment, the computing device 200 also includes apresentation unit 206 that is coupled to (and that is in communicationwith) the processor 202 (however, it should be appreciated that thecomputing device 200 could include output devices other than thepresentation unit 206, etc.). The presentation unit 206 outputsinformation (e.g., indicators of requested data, etc.), visually oraudibly, for example, to a user of the computing device 200 (e.g., auser associated with the requesting party 108, etc.), etc. And, variousinterfaces (e.g., as defined by network-based applications, websites,etc.) (e.g., including instructions relating to user data and/or PII,etc.) may be displayed at computing device 200, and in particular atpresentation unit 206, to display certain information. The presentationunit 206 may include, without limitation, a liquid crystal display(LCD), a light-emitting diode (LED) display, an organic LED (OLED)display, an “electronic ink” display, speakers, etc. In someembodiments, presentation unit 206 may include multiple devices.

In addition, the computing device 200 includes an input device 208 thatreceives inputs from the user (i.e., user inputs) of the computingdevice 200 such as, for example, data relating to the user 114, etc., inresponse to appropriate prompts. The input device 208 may include asingle input device or multiple input devices. The input device 208 iscoupled to (and is in communication with) the processor 202 and mayinclude, for example, one or more of a keyboard, a pointing device, amouse, a stylus, a camera, a biometric reader (e.g., a fingerprintscanner, etc.), a touch sensitive panel (e.g., a touch pad or a touchscreen, etc.), another computing device, and/or an audio input device.In various exemplary embodiments, a touch screen, such as that includedin a tablet, a smartphone, or similar device, may behave as both thepresentation unit 206 and an input device 208.

Further, the illustrated computing device 200 also includes a networkinterface 210 coupled to (and in communication with) the processor 202and the memory 204. The network interface 210 may include, withoutlimitation, a wired network adapter, a wireless network adapter (e.g.,an NFC adapter, a Bluetooth™ adapter, etc.), a mobile network adapter,or other device capable of communicating to one or more differentnetworks herein (such as network 110) and/or with other devicesdescribed herein. Further, in some exemplary embodiments, the computingdevice 200 may include the processor 202 and one or more networkinterfaces incorporated into or with the processor 202.

Referring again to FIG. 1, in general in the system 100, the user 114initially enrolls a digital identity to the identity host 102. Inparticular, the identity host 102 is configured to provide anetwork-based interface (e.g., a website, an application (e.g., avirtual wallet application, etc.), etc.) to the user 114 at thecomputing device 112, which solicits entry of personal identifyinginformation (PII) for the user 114 and/or capture of physical documentsrelated to the user's personal identifying information (PII). Forexample, the network-based interface may solicit entry of the name,mailing address, phone number, birth date, and social security number ofthe user 114, and may further be configured to capture or otherwiseprovide an image of the user's passport. What's more, in variousembodiments the identity host 102 may rely on and/or utilize one or moreentities, such as, for example, an identity verification service, toauthenticate the personal identifying information and/or the physicaldocument image(s) received from the user 114.

Optionally, in connection with such enrollment of the user 114, theidentity host 102 may be configured to solicit information sufficient toauthenticate the user 114. For example, the identity host 102 may beconfigured to solicit a facial image of the user 114 for comparison toan image included in one or more of the physical documents captured,etc. In connection therewith, the identity host 102 may be configured toalso solicit other information about the user 114, either biometric orotherwise, where the information is known to the identity host 102through one or more other entities (e.g., a payment network into whichthe identity host 102 is integrated, a related financial institution,etc.). In addition, rather than soliciting information known through oneor more entities for use in authenticating the user 114, the identityhost 102 may be configured to rely, in whole or in part, onauthentication services from other entities, such as, for example, auser authentication service associated with a virtual wallet applicationassociated with the user 114, etc.

Then, once the personal identifying information is received from theuser 114 (via the network-based interface) and authentication of theuser 114 is received and/or complete, the identity host 102 isconfigured to compile a digital identity for the user 114 and store thedigital identity in memory (e.g., in the memory 204, etc.), therebycompleting enrollment of the user 114 with the identity host 102.

Moreover, after enrollment of the user 114, the identity host 102 isconfigured to enroll the attribute providers 104 and 106. In doing so,the identity host 102 effectively links the user's identity kept at theidentity host 102 with the user's identity kept at the attributeproviders 104 and/or 106, as applicable. For example, the identity host102 may be configured to link the user 114 to the identifyinginformation at the attribute provider 104 by a mobile phone number, orgovernment ID (e.g., a social security number, etc.), whereby, whenrequested by the identity host 102, the attribute provider 104 isconfigured to identify the user 114 to which the request is related (asdescribe below) via the link, for example.

Subsequently in the system 100, the user 114 may interact with therequesting party 108 for one or more reasons (as described above), wherethe requesting party 108 in turn requests verification of the user'sidentity and/or an attribute about the user 114. In response, herein,the user 114 accesses the identity host 102, via the network-basedinterface described above (as provided by the identity host 102) or viaone or more other network-based interfaces, and solicits an identitycode (generally based on his/her digital identity). Optionally, inconnection with such request for the identity code (and as providedabove), the computing device 112 and/or the network-based interface maybe configured to authenticate the user 114, prior to permitting therequested interaction with the identity host 102 or as part of theinteraction with the identity host 102. In this manner, only the user114 is able to request an identity code associated with his/her digitalidentity, as stored at the identity host 102. After authentication, whenutilized, the user's request is received at the identity host 102, andthe identity host 102 is configured to generate the identity code, storethe identity code in memory (e.g., in the memory 204, etc.), andassociate the identity code with the digital identity of the user 114(e.g., in the memory 204, etc.).

The identity host 102 then returns the identity code to the user 114, atthe user's computing device (from which the request originated). Theidentity code may include an alpha-based code, a numeric code, analpha-numeric code, or other code, which is generally a one-time codeand usable for only a limited interval (e.g., one hour, five hours, oneday, etc.). In requesting the identity code, the user 114 may alsodesignate the requesting party 108 as authorized and/or approved, viathe network-based interface, to permit interaction between the identityhost 102 and the requesting party 108, as desired and/or needed.

Upon receipt of the identity code from the identity host 102, the user114 provides the identity code to the requesting party 108. In turn, therequesting party 108 is configured to compile and transmit a request tothe identity host 102 for verification of the identity code (and, thus,the user 114). In general, the request will include at least one query,which is answerable by Yes/No (or True/False or 1/0) responses (e.g.,“Does the user's social security number include 331?”, or “Is the user114 a male over the age of twenty-one?” (i.e., an age threshold query),or “Does the user 114 have more than $100,000 in liability insurancecoverage?”, or “Has the user spent more than $15,000 in the last threemonths on the payment account ending in 1234?”, etc.). While generallyin this form, the request may include other types of queries thatrequest PII or parts of PII, but that can generally be answered withoutactually transmitting the PII or substantially transmitting the PII (tothe point where the user 114 may be identified) (e.g., “What are thelast four characters of the user's driver's license number?” or What isthe name of the user's insurance company?” or “Is the user older than25, have collision insurance over $30,000 that covers rental cars, andlicensed to drive in the United States?” or “Has the user spent morethan $10,000 across all credit cards in the past month and does the userhave a credit score over 300?” or “Does the user live within 200 milesof ZIP code 12345 and has the user shopped online in the past sixmonths?” etc.). With that said, regardless of whether the query is anactual Yes/No query, or not, the requesting party 108 may be providedwith certain forms for queries to the identity host, such as, forexample, “Is [name] over [years] of age?” or “Does [name] have insuranceof [type of insurance] over [threshold amount]?” or “Does [name] endwith/start with/include [value]?”, etc., whereby certain variablesand/or forms are used to identify content of the query to the identityhost 102. What's more, the requesting party 108 may be encouraged toinclude certain keywords in the request to aid the identity host 102 inrecognizing the query, such as age, insurance, social security number,ZIP code, miles, coverage, etc. Moreover, and even regardless of theform/type of the query included/submitted by the requesting party 108,the request will generally include the identity code received from theuser 114 (so that the identity host 102 may verify the code).

In this exemplary embodiment, the request compiled by the requestingparty 108 is transmitted to the identity host 102 via an OPAL™ query(see, http://www.opalproject.org/about-us/, which is incorporated hereinby reference), or other suitable type of query, which may be provided asan application programming interface (API) or otherwise, and whichattempts to act and/or acts to preserve the privacy of the data includedin the request as would be understood by those skilled in the art. Withthat said, other mechanisms of querying the identity host 102, by therequesting party 108, for example, may be employed in other embodiments.

It should be appreciated, that when the request is submitted, theidentity host 102 may be configured to transmit a confirmation requestto the user 114, whereby the confirmation request may indicate therequesting party 108 and also the specific query by the requesting party108. In doing so, the identity host 102 may further be configured tosolicit a confirmation and/or acknowledgement to proceed, and/or evenone or more inputs altering, expanding, or restricting the query tocertain information to be provided. When the identity host 102 isconfigured in this way, the user 114 is provided with certain controlover the requests for the user's identifying information therebypreventing queries from extending beyond what is relevant and/ornecessary to the requesting party's purpose.

In turn in the system 100, upon receiving the request from therequesting party 108, the identity host 102 is configured to verify theidentity code included in the request, thereby identifying the user 114,and to submit the request to the appropriate one(s) of the attributeproviders 104 and 106, if any. The request, when submitted to theappropriate one(s) of the attribute providers 104 and 106, is submittedagain via an OPAL™ query, or other suitable type of query, as describedabove. The identity host 102 is configured, in general, to identify theattribute providers 104 and 106 based on the enrollment above. Inaddition, the request generally includes certain identifying informationfor the user 114, which permits the appropriate one(s) of the attributeproviders 104 and 106 the ability to identity the user 114, as referredto herein, via one or more links. Such links may include, for example,the name, the address, the mobile phone number, the social securitynumber, driver's license number, and/or passport number of the user 114,etc. The attribute providers 104 and 106, in turn, are configured toidentify the user 114 based on the one or more links The appropriateone(s) of the attribute providers 104 and 106 is/are configured toreceive the request from the identity host 102, to identify the user 114(based on the information in the request), to determine an attributeresponse to the query (e.g., including an answer to the query, etc.)based on identifying information held by the attribute provider 104and/or 106, and to provide the attribute response back to the identityhost 102.

Conversely, when the query associated with the request from therequesting party 108 is directed to information held by the identityhost 102, for example, received in connection with enrollment of theuser 114 or otherwise (e.g., a social security number of the user 114,an age of the user 114, etc.), the identity host 102 may be configuredto omit transmitting the request to either of the attribute providers104 and 106 and to compile and provide the response to the requestingparty 108 directly.

In the illustrated system 100, regardless of whether a response to therequest provided by the requesting party 108 is compiled at one of theattribute providers 104 and 106 or at the identity host 102, theresponse includes a limited amount of information about the user 114(e.g., an insufficient amount of information to particularly identifythe user 114 on its own, etc.). That is, a query regarding whether theuser is greater than 25 years of age may simply return a response of“Yes” or “No”, and not the actual age of the user 114. As such, when theresponse is compiled by one of the attribute providers 104 and 106, theidentity host 102 will not, generally, in this embodiment, receive thepersonal identifying information upon which the response is based (e.g.,the user's birth date, etc.). Likewise, the requesting party 108 willreceive just a response to the query and not the data on which theresponse is based (e.g., and not any additional personal identifyinginformation for the user 114, etc.).

What's more, the identity host 102 may be configured to imposerestrictions on the number, type or permutation of queries from therequesting party 108. For example, the identity host 102 may restrictthe requesting party 108 from submitting further queries related to age,based on prior identity request(s) related to age, whereby the user'sage may be known (e.g., when a prior query of “is the user older than26?” has already been submitted, then a later query of “is the useryounger than 28?” may be restricted; etc.). That said, the requestingparty 108 may be configured to permit multiple of the same requests,even when related to the same identifying information. That is, forexample, a bar business may repeatedly submit identity requests aboutwhether the user 114 is over 21 years of age (i.e., an age threshold),and answering that query multiple times does not further disclose theuser's actual age. It should be appreciated that the identity host 102may be configured to thus impose these and other restrictions on one ormore queries, within a request or multiple requests, to protectunintended disclosures of identifying information.

FIG. 3 illustrates an exemplary method 300 for use in responding toqueries related to a user, based on a digital identity of the user. Theexemplary method 300 is described (with reference to FIG. 1) asimplemented in the identity host 102, the attribute providers 104 and106, the requesting party 108, and the user 114 (and computing device112) of the system 100. Reference is also made to the computing device200 of FIG. 2. However, the methods herein should not be understood tobe limited to the system 100 or the computing device 200, as the methodsmay be implemented in other systems and/or computing devices. Likewise,the systems and the computing devices herein should not be understood tobe limited to the exemplary method 300.

In the method 300, after enrollment of the user 114 and the attributeproviders 104 and 106 with the identity host 102, the user 114 interactswith the requesting party 108 for one or more purposes. For example, theuser 114 may request a credit line from the requesting party 108, orrequest a car rental from the requesting party 108, or request a bonustravel offer from the requesting party 108 based on high spending, etc.In any case, upon interaction with the requesting party 108, or prior,the user 114 is initially authenticated, at 302, by the identity host102, as generally described above in the system 100 (e.g., based on abiometric received from the user 114, based on a personal identificationnumber (PIN) received from the user 114, based on interaction of theuser 114 with the network-based interface associated with the identityhost 102, etc.). By authenticating the user 114, it should beappreciated that certain fraudulent and/or unauthorized requests foridentity codes from the identity host 102 may be limited and/oreliminated. What's more, while certain example interactions are providedherein between the user 114 and the requesting party 108 (whereby therequesting party 108 desires to verify an identity of the user 114), itshould be appreciated that the method 300 is not limited to theseexamples and may be employed and/or adapted to other bases forinteractions between the user 114 and the requesting party 108.

Next in the method 300, once the user 114 is authenticated, the user 114transmits a request, at 304, via the computing device 112, for anidentity code, to the identity host 102. The request includes anindication of the user 114 (e.g., based on the authentication of theuser 114, based on a device ID or application ID associated with theuser's computing device 112, based on an input by the user 114, etc.),and may further include a designation of the requesting party 108thereby forecasting that the request is from/for the requesting party108. In addition, the request may also include one or more limitationsand/or descriptions of the personal identifying information that mightbe sought by the requesting party 108.

In turn, the identity host 102 receives the request from the user 114and generates, at 306, the identity code, which may include, forexample, a unique, one-time use identity code associated with the user114. In doing so, the identity host 102 further stores the identity codein memory (e.g., the memory 204, etc.) in association with the user'sdigital identity (as generated for the user 114 upon registration of theuser 114 with the identity host 102, etc.). The identity code mayinclude any type of code, which may be alpha, numeric, alpha-numeric,symbol, machine readable symbol, or otherwise. One example of anidentity code includes a barcode or a QR code, while another exampleidentity code includes a globally unique identifier (GUID), or auniversally unique identifier (UUID). Moreover, optionally, the identitycode may be associated with the requesting party 108, such that theidentity code includes an identifier for the requesting party 108 and/oris associated therewith in memory (e.g., the memory 204, etc.), wherebythe requesting party 108, when submitting the identity code, may beverified as associated with the identity code, as indicated below.Thereafter, the identity host 102 transmits, at 308, the identity codeback to the user 114, at the computing device 112.

The user 114, then, provides the identity code to the requesting party108, at 310. The user 114 may provide the identity code to therequesting party 108 by merely reading the identity code to therequesting party 108. Additionally, or alternatively, the user'scomputing device 112 may display the identity code for viewing by therequesting party 108, or it may display a computer-readable symbol(e.g., a QR code, a barcode, etc.) at the presentation unit 206, of thecomputing device 112, for scanning or capture by the requesting party108. In general, the manner in which the identity code is provided tothe requesting party will be dependent, at least on part of the form,format and/or type of identity code provided to the requesting party108.

In any case, the requesting party 108 receives and/or captures theidentity code, and identifies, at 312, one or more queries that relateto the user 114 and/or attributes associated with the user 114 as may berelevant to its interaction of the user 114 with the requesting party108 (e.g., based on the product and/or service requested by the user 114from the requesting party 108, etc.). For example, where the requestingparty 108 is a rental car business, the requesting party 108 mayidentify queries related to an age of the user 114 being overtwenty-five, the user 114 having collision insurance coverage of $30,000or more, and the user 114 having a valid driver's license in the UnitedStates. Similarly, when the requesting party 108 is a bankinginstitution and the user 114 desires to open a new account, therequesting party 108 may identify queries related to the user's spendover the past six month, the user's spend over the last month, a numberof transactions performed by the user 114 in a given interval, a creditscore for the user 114 being above or below a threshold, etc. It shouldbe appreciated that any number of different queries, depending on thetype of interaction between the user 114 and the requesting party 108,may be identified as described herein. In at least one embodiment, therequesting party 108 merely identifies a subject matter for the request,the requesting party 108, and/or a designation or other indicatorrelated thereto, and the identity host 102 then identifies theparticular queries to which it will respond (rather than the requestingparty 108 identifying the actual queries).

Once the desired queries are identified for the user's request(regardless if identified by the requesting party 108 or the identityhost 102), the requesting party 108 submits, at 314, an identity requestto the identity host 102. The identity request includes each of theidentified queries (or an indicator by which the identity host 102 thenidentifies the appropriate queries) and the identity code received fromthe user 114. The request is submitted to the identity host 102, via theOPAL™ API query (and/or other suitable query). The identity host 102receives the request and, optionally, verifies the identity code inmemory (e.g., as being generated by the identity host 102 and/orassociated with the user 114, etc.), and then once verified, identifies(and confirms) the user 114, at 316, based on the identity code (e.g.,the identity host 102 compares the identity code received from therequesting party 108 to the identity code provided to the user 114 (at308), etc.).

Further, and optionally, the identity host 102 may request confirmationfrom the user 114 and/or check restrictions on the queries included inthe identity request, at 318. In particular, the identity host 102 mayseek a confirmation and/or acknowledgement of the request, and/or thequery of the request, from the user 114 for the specific request. Theacknowledgement, when received from the user 114, may provide a generalpermission to proceed, or may include a restriction on the identifyinginformation returned to the requesting party 108. Then, the identityhost 102 imposes the restriction on the query. And also, the identityhost 102 may impose restrictions to protect again unintended disclosuresof identifying information through a series of questions. For example,an exemplary restriction may limit the age based queries to one or morequeries, including in one or more prior identity requests, beforerestricting all other queries, to prevent or inhibit the requestingparty from “zeroing in” on the age of the user 114, or some otherattribute of the user 114, etc. By imposing the restrictions, theidentity host 102 may alter the query, or simply return an error orfailed query message to the requesting party 108.

Then, subject to the restrictions, if any, at 320, the identity host 102identifies one or more of the attribute providers 104 and 106 forresponding to the queries (i.e., the attribute provider(s) having aportion of identifying information suitable to answer the query(ies)).In general, the identity host 102 will employ rules associated with thequeries, whereby the appropriate ones of the attribute providers 104 and106 will be identified for the particular one or more of the queries,for example, through enrollment of the attribute providers 104 and/or106 and/or assignment of rules to the identifying data captured and/orstored by the particular attribute providers. In particular, in therental car example, the identity host 102 may identify the attributeprovider 104, which is an insurance provider in this example, forqueries related to insurance coverage, and may identify the attributeprovider 106, which is a department of motor vehicles in the state ofthe user's residence in this example, for queries related to whether ornot the user 114 has a valid driver's license, and may identify itselfas an attribute provider for queries related to age of the user 114. Itshould be appreciated that the attribute providers 104 and 104 may beotherwise in other examples, but are specified here as an insuranceprovider and a department of motor vehicles for purposes of illustrationonly.

Then in the method 300, the identity host 102 determines, at 322, aresponse to the query(ies) for which it is the attribute provider. Forinstance, in the above car rental example, the identity host 102 (actingas an attribute provider) determines whether the user 114 is overtwenty-five yes old. In particular, the identity host 102 determinesthat the user 114 is thirty-four years old based on the birth date ofthe user 114 included in the digital identity for the user 114associated with the provided identity code, and thus determines theresponse to the query is “Yes.” Optionally, the identity host 102, uponreceiving the request from the requesting party 108, or later (but priorto transmitting a response), may determine and/or confirm that therequesting party 108 is associated with the identity code as included inthe original request. In this manner, the requesting party 108 may betied back to the request from the user 114 thereby providing furthersecurity and/or checking associated with the digital identity inquiry.

In addition, the identity host 102 submits, at 324, to the attributeprovider 104, the query(ies) for which the attribute provider 104 isidentified (e.g., the insurance coverage query in the above example,etc.). The query includes, or is accompanied by, at least some personalidentifying information for the user 114, as provided from the user'sdigital identity associated with the identity code received from therequesting party 108. This identifying information provides one or morelinks, such as, for example, a the mobile phone number, the socialsecurity number, driver's license number, and/or passport number of theuser 114, etc. The one or more links may be the same for each request tothe attribute provider 104, or it may be different (e.g., for thedifferent attribute providers 104 and/or 106, etc.). For example, asocial security number, or mobile phone number, may be used in aninitial request (or at enrollment of the attribute provider 104, forexample) and then some other link, for example, a GUID, may be used asthe one or more links for subsequent requests or for the other attributeprovider 106. In this manner, certain identifying information may beremoved and/or protected from the subsequent requests. In turn, theattribute provider 104 determines, at 326, an attribute response to thequery(ies) received from the identity host 102 (e.g., a response to theinsurance coverage query, etc.). In particular, the attribute provider104 identifies the user 114 based on the personal identifyinginformation provided in or with the query and then determines, based onidentifying information, an answer to the query. In the above example,the attribute provider 104 determines whether the user 114 has thespecific coverage required by the requesting party 108. Here, theattribute provider 104 determines the user 114 has $100,000 in liabilitycoverage, and the response to the query is then “Yes.” The attributeprovider 104 then transmits an attribute response, including the “Yes”answer and/or the birthdate attribute (whereby the identity host 102 isable to then determine the answer to the query, etc.), back to theidentity host 102, at 328, but not, in this example, the specificinformation related to the $100,000 liability coverage. That informationis instead retained at the attribute provider 104.

Similarly, the identity host 102 submits, at 330, to the attributeprovider 106, the query(ies) for which the attribute provider 106 isidentified (e.g., the valid driver license query in the above example,etc.). The query includes, or is accompanied by, at least some personalidentifying information for the user 114 as provided from the user'sdigital identity associated with the identity code received from therequesting party 108. The attribute provider 106 then determines, at332, a response to the query(ies) received from the identity host 102(e.g., a response to the insurance coverage query, etc.). In particular,the attribute provider 106 identifies the user 114 based on the personalidentifying information provided in or with the query and thendetermines, in the above example, whether the user 114 has a validdriver's license in the state as required by the requesting party 108.Here, the attribute provider 106 determines the user 114 has held avalid driver's license for fifteen years and his/her current licenseexpires in two months, and the response to the query is “Yes.” Theattribute provider 106 transmits the “Yes” response back to the identityhost 102, at 334, but not, in this example, the specific duration forwhich the user's driver's license has been held or that it expires intwo months. Again, that information is instead retained at the attributeprovider 106.

It should be appreciated that any different number of queries may beincluded by the identity host 102 than described above and/or that adifferent number of attribute providers may be queried in otherembodiments, depending on, for example, the queries submitted by therequesting parties and the data specific to the users in the possessionof the particular attribute providers.

Finally in the method 300, once the identity host 102 receives responsesto each of the queries, the identity host 102 compiles a response to therequesting party 108, at 336. The response may be representative ofmultiple responses, or it may be specific to each response, determinedby the identity host 102 or received from the attribute providers 104and 106, etc. Specifically, the identity host 102 may compile a singleresponse of “Yes,” thereby representing each of the “Yes” responsesdetermined and/or received. Or, the identity host may compile a responseof “Yes,” “Yes,” “Yes,” where each discrete response is included foreach of the three different queries. Regardless of form, after compilingthe response, the identity host 102 transmits the response back to therequesting party 108, at 338, thereby informing the requesting party 108about the user 114. As a result, the requesting party 108 is able tocontinue in its interactions with the user 114 (e.g., renting a car,etc.), or not.

In view of the above, the systems and methods herein permit requestingparties to submit queries relating to identifying users interacting withthe requesting parties, where the queries are tied to identity codesspecific to users (and corresponding digital identifies for the users).In response to the queries, an identity host is able to provide aresponse, determined by the identity host and/or an attribute providerseparate therefrom, where the requesting party is informed about a user(e.g. about attributes of the user, etc.), while superfluous and/orunnecessary personal identifying information for the user is notprovided to the requesting party (or potentially, the identity host),and often without relaying specific identifying information of the user(e.g., indicating that the user is over 21 years of age, but withoutdisclosing the exact birthdate of the user, etc.). In this manner, theprivacy of the user is maintained, while permitting the requesting partyto receive information and/or confirmations needed for proceeding ininteractions with the user (e.g., renting a car, opening an account,providing offers, etc.).

Again and as previously described, it should be appreciated that thefunctions described herein, in some embodiments, may be described incomputer executable instructions stored on a computer readable media,and executable by at least one processor (in the same of differentcomputing devices). The computer readable media is a non-transitorycomputer readable storage medium. By way of example, and not limitation,such computer-readable media can include RAM, ROM, EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium that can be used to carry or storedesired program code in the form of instructions or data structures andthat can be accessed by a computer. Combinations of the above shouldalso be included within the scope of computer-readable media.

It should also be appreciated that one or more aspects of the presentdisclosure transform a general-purpose computing device into aspecial-purpose computing device when configured to perform thefunctions, methods, and/or processes described herein.

As will be appreciated based on the foregoing specification, theabove-described embodiments of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof,wherein the technical effect may be achieved by performing at least oneof the following operations: (a) receiving a request for an identitycode for a user, the user associated with identifying information andthe identifying information including multiple attributes of the user;(b) generating and transmitting the identity code for the user to theuser at a computing device associated with the user, thereby permittingthe user to present the identity code to a requesting party; (c)receiving an identity request from the requesting party including atleast one query related to at least one of the multiple attributes ofthe user and including the identity code for the user; (d) identifyingthe user based on the identity code; (e) compiling a response to the atleast one query of the identity request based on the identifyinginformation of the user from at least one attributed provider; (f)transmitting the response to the requesting party, thereby permittingthe requesting party to be informed about the identity of the user; (g)authenticating the user prior to receiving the request for the identitycode for the user; (h) seeking, by the computing device, confirmationfrom the user, associated with the identity request, prior to compilingthe response to the identity request; and (i) restricting the responseto the requesting party based on at least one prior identity requestfrom the requesting party when the identity request and the at least oneprior identity request related to a same one of the multiple attributesof the user.

Exemplary embodiments are provided so that this disclosure will bethorough, and will fully convey the scope to those who are skilled inthe art. Numerous specific details are set forth such as examples ofspecific components, devices, and methods, to provide a thoroughunderstanding of embodiments of the present disclosure. It will beapparent to those skilled in the art that specific details need not beemployed, that example embodiments may be embodied in many differentforms and that neither should be construed to limit the scope of thedisclosure. In some example embodiments, well-known processes,well-known device structures, and well-known technologies are notdescribed in detail.

The terminology used herein is for the purpose of describing particularexemplary embodiments only and is not intended to be limiting. As usedherein, the singular forms “a,” “an,” and “the” may be intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. The terms “comprises,” “comprising,” “including,” and“having,” are inclusive and therefore specify the presence of statedfeatures, integers, steps, operations, elements, and/or components, butdo not preclude the presence or addition of one or more other features,integers, steps, operations, elements, components, and/or groupsthereof. The method steps, processes, and operations described hereinare not to be construed as necessarily requiring their performance inthe particular order discussed or illustrated, unless specificallyidentified as an order of performance. It is also to be understood thatadditional or alternative steps may be employed.

When a feature is referred to as being “on,” “engaged to,” “connectedto,” “coupled to,” “associated with,” “included with,” or “incommunication with” another feature, it may be directly on, engaged,connected, coupled, associated, included, or in communication to or withthe other feature, or intervening features may be present. As usedherein, the term “and/or” includes any and all combinations of one ormore of the associated listed items.

Although the terms first, second, third, etc. may be used herein todescribe various features, these features should not be limited by theseterms. These terms may be only used to distinguish one feature fromanother. Terms such as “first,” “second,” and other numerical terms whenused herein do not imply a sequence or order unless clearly indicated bythe context. Thus, a first feature discussed herein could be termed asecond feature without departing from the teachings of the exampleembodiments.

None of the elements recited in the claims are intended to be ameans-plus-function element within the meaning of 35 U.S.C. § 112(f)unless an element is expressly recited using the phrase “means for,” orin the case of a method claim using the phrases “operation for” or “stepfor.”

The foregoing description of exemplary embodiments has been provided forpurposes of illustration and description. It is not intended to beexhaustive or to limit the disclosure. Individual elements or featuresof a particular embodiment are generally not limited to that particularembodiment, but, where applicable, are interchangeable and can be usedin a selected embodiment, even if not specifically shown or described.The same may also be varied in many ways. Such variations are not to beregarded as a departure from the disclosure, and all such modificationsare intended to be included within the scope of the disclosure.

What is claimed is:
 1. A computer-implemented method for use inresponding to attribute queries related to identifying information for auser, based on a digital identity of the user, the method comprising:receiving, by an identity host computing device, a request for anidentity code for a user from a user computing device associated withthe user, the user associated with identifying information and theidentifying information including multiple attributes of the user; inresponse to the request for the identity code, generating, by theidentity host computing device, the identity code for the user andtransmitting the identity code to the user computing device, therebypermitting the user to present the identity code to a requesting party,and wherein the identity code (i) includes an identification specific tothe requesting party, (ii) is a one-time code and (iii) does not includeidentifying information of the user; receiving, at the identity hostcomputing device, an identity request from the requesting partyincluding at least one query specific to at least one of the multipleattributes of the user and including the identity code for the user; inresponse to the identity request: identifying, by the identity hostcomputing device, the user based on the identity code; verifying, by theidentity host computing device, that the identification of therequesting party is specific to the requesting party based on theidentity code; and compiling, by the identity host computing device, aresponse to the at least one query of the identity request, the responseincluding an answer to the at least one query based on the at least oneof the multiple attributes of the user included in the identifyinginformation of the user from at least one attribute provider, whereinthe response excludes the at least one of the multiple attributes of theuser; and transmitting the response to the requesting party, therebypermitting the requesting party to be informed about the identity of theuser based on the answer to the at least one query, without revealingthe identifying information of the user to the requesting party.
 2. Thecomputer-implemented method of claim 1, further comprisingauthenticating the user prior to receiving the request for the identitycode for the user.
 3. The computer implement method of claim 1, furthercomprising seeking, by the identity host computing device, confirmationof the identity request from the user associated with the identityrequest, prior to compiling the response to the identity request.
 4. Thecomputer-implemented method of claim 1, further comprising: identifying,by the identity host computing device, the at least one attributeprovider based on at least one attribute identified in the at least onequery; submitting, by the identity host computing device, the at leastone query to the identified at least one attribute provider; andreceiving an attribute response from the at least one attribute providerto the at least one query; and wherein compiling the response to the atleast one query of the request includes compiling the response based onthe attribute response from the at least one attribute provider.
 5. Thecomputer-implemented method of claim 1, wherein the at least one queryincludes at least a first query and a second query and wherein the atleast one attribute provider includes a first attribute provider and asecond attribute provider; and wherein the method further comprises:submitting the first query to the first attribute provider; receiving afirst attribute response from the first attribute provider, the firstattribute response including a response to the first query; submittingthe second query to the second attribute provider; and receiving asecond attribute response from the second attribute provider, the secondattribute response including a response to the second query; and whereincompiling the response to the at least one query of the identity requestincludes compiling the response based on the first attribute responseand the second attribute response.
 6. The computer-implemented method ofclaim 5, further comprising identifying, by the identity host computingdevice, the first attribute provider based on the first query, prior tosubmitting the first query to the first attribute provider.
 7. Thecomputer-implemented method of claim 1, further comprising storing adigital identity for the user in memory coupled to the identity hostcomputing device; and wherein identifying the user based on the identitycode includes identifying the user to the digital identity in the memorybased on the identity code.
 8. The computer-implemented method of claim1, further comprising rejecting a query of a subsequent identity requestwhen the query of the subsequent identity request is different than theat least one query of the identity request but is specific to a same oneof the multiple attributes of the user included in the at least onequery of the identity request.
 9. A system for use in responding toattribute queries related to identifying information for a user, thesystem comprising: an identity host computing device configured to:receive a request for an identity code for a user, the user associatedwith identifying information including multiple attributes; in responseto the request for the identity code, generate the identity code for theuser and transmit the identity code to the user at a communicationdevice associated with the user, wherein the identity code is a one-timecode and does not include identifying information of the user; receivean identity request from a requesting party including the identity codeand at least a first query specific to at least one of the multipleattributes of the user; in response to the identity request: submit thefirst query to a first attribute provider; receive an attribute responsefrom the first attribute provider; compile a response to the identityrequest received from the requesting party, wherein the response to theidentity request includes an answer to the first query, the answerindicative of the at least one of the multiple attributes and based onthe attribute response from the first attribute provider, wherein theresponse to the identity request excludes the at least one of themultiple attributes of the user; and transmit, to the requesting party,the response to the identity request, thereby permitting the requestingparty to be informed about an identity of the user by the answer to thefirst query, without revealing the identifying information of the userto the requesting party; and then in response to at least one subsequentidentity request: reject a query of one of the at least one subsequentidentity request when the query of the one of the at least onesubsequent identity request is different than the first query of theidentity request, but specific to a same one of the multiple attributesincluded in the first query of the identity request.
 10. The system ofclaim 9, wherein the identity host computing device is furtherconfigured to authenticate the user prior to generating the identitycode in response to the request for the identity code.
 11. The system ofclaim 9, wherein the identity host computing device is furtherconfigured to identify the user based on the identity code and toidentify the first attribute provider based on the user and at least oneattribute indicated by the first query.
 12. The system of claim 9,wherein the at least one of the multiple attributes of the user includesat least one of an age, a prior purchase, and an insurance coverage ofthe user.
 13. The system of claim 9, wherein the first query includes aquery directed to an age of the user relative to an age threshold. 14.The system of claim 9, wherein the identity host computing device isfurther configured to submit a second query, included in the identityrequest and specific to at least another one of the multiple attributesof the user, to a second attribute provider; and wherein the response tothe identity request is further based on a second attribute responsereceived from the second attribute provider in response to the secondquery.
 15. A non-transitory computer readable storage medium includingcomputer-executable instructions for responding to attribute queriesrelated to identifying information for a user, which, when executed byat least one processor of an identity host computing device, cause theat least one processor to: receive a request for an identity code for auser, from a mobile device of the user, the user associated withidentifying information and the identifying information includingmultiple attributes of the user; in response to the request for theidentity code, generate the identity code for the user and transmit theidentity code to the user at the mobile device of the user, therebypermitting the user to present the identity code to a requesting party,and wherein the identity code is a one-time code and does not includeidentifying information of the user; receive an identity request fromthe requesting party, the identity request including the identity codeand a first query related to identifying information associated with theuser; and in response to the identity request: submit the first query toa first attribute provider having at least a portion of the identifyinginformation for the user, where the at least a portion of theidentifying information is indicative of an answer to the first query;and compile, and transmit to the requesting party, a response to theidentity request, the response including the answer to the first querybased on an attribute response from the first attribute provider,wherein the response to the identity request excludes the portion of theidentifying information indicative of the answer to the first query,thereby permitting the requesting party to be informed about theidentity of the user by the answer to the first query, without revealingthe identifying information of the user to the requesting party; andthen in response to at least one subsequent identity request, reject aquery of the at least one subsequent identity request based on an inputfrom the user and/or when the query of the at least one subsequentidentity request is different than the first query of the identityrequest but is related to a same portion of identifying informationincluded in the first query of the identity request.
 16. Thenon-transitory computer readable storage medium of claim 15, wherein theidentity request includes a second query; wherein thecomputer-executable instructions, when executed by the at least oneprocessor, further cause the at least one processor to submit the secondquery to a second attribute provider having at least a second portion ofthe identifying information for the user, where the second portion ofthe identifying information is different from the portion of theidentifying information at the first attribute provider and isindicative of an answer to the second query; and wherein the response tothe identity request includes the answer to the second query, based on asecond attribute response from the second attribute provider, andwherein the response to the identity request excludes the second portionof the identifying information indicative of the answer to the secondquery, thereby further permitting the requesting party to be informedabout the identity of the user by the answer to the second query withoutrevealing the identifying information of the user to the requestingparty.
 17. The computer-implemented method of claim 1, wherein the atleast one of the multiple attributes is a government identificationnumber, and wherein the answer to the at least one query includes only aportion of the government identification number.